前言

過去在各企業講授 Azure DevOps 課程時，總會苦口婆心要學員們注意 Pipeline 所使用的 Task，尤其是從 Visual Studio Marketplace - Extensions for Azure DevOps 安裝的，盡可能選擇知名組織、評價較好且有開放原始碼(能在 GitHub 能看到原始碼佳)的 Task 使用，以避免發生資安問題。

選擇 Task 的原則也適用於 GitHub Action

過去在學習 GitHub/備課 Azure DevOps 時期也注意到 Pipeline Task 有版本號碼 (如：以 Maven Task 為例，版號不同所使用的參數不同，但可以做到更多事情)，但隨著時間推進，漸漸遺忘的教材中曾提到版本號碼組成與使用原理。在一次平台管理事故中狠狠的敲我一棒，讓我了解這個版本管理相當重要，好險憑印象還記得怎麼固定版號，順利解決問題。

管理 Task 版本

Task 版號相當有趣，當使用者選擇在傳統編輯器選擇 1.* ，或在 YAML 內設定 @1，其實指定版本 1.X 中最新版本。一旦官方/開發人員有更新 (如 1.8.1 更新至 1.9.2)，你的 Pipeline 執行時，會自動拉取 1.9.2 版本來用。理所當然，在官方的最佳實踐內會建議盡可能使用最新版號，會有較好的安全性，所以預設會使用版號，達到上述即時使用新版本 Task 效果。

過去一個事故經驗發生在 Bash Task (由微軟提供，原始碼在 microsoft/azure-pipelines-tasks)，正常運作的 Pipeline 內使用的 Bash Task 忽然出現意想不到的語法錯誤，在同仁仔細比對上一次成功執行診斷訊息後，發現版本號碼增加了。在固定版本號碼後，Bash Task 恢復正常運作，並回報微軟、GitHub 建立 Issue，或檢視該版本做了那些更新，視情況調整 Bash 內容。其解決問題流程大致如下：

1. 找到上次成功執行的 Pipeline，記錄下 Commit
   

2. 指定 Branch/Commit 並啟用系統診斷，執行 Pipeline

啟用系統診斷原因是有些 Task 有提供 Version 的 input，透過系統診斷可以看見這些參數

3. 從 Pipeline Log 中找到版號
   

4. 修改 Pipeline YAML 內 Bash Task 版號
   

5. 重新執行確認問題排除

其他 Task 最佳實踐

1. 避免遠端取得資源，但如有必要，請使用版本控制和雜湊檢查
2. 不要記錄 Secret
3. 不要將 Secret 儲存在 Pipeline variables中，請使用 Azure KeyVault。 定期掃描您的建置管道，以確保機密不會儲存在建置管道變數中
4. 不要讓使用者針對安全關鍵 Pipeline 上的任意分支或標籤執行建置
5. 停用 Pipeline 上的繼承，因為繼承的權限很廣泛，並且不能準確反應您對權限的需求
6. 在所有情況下限制工作授權範圍

節錄 Microsoft Docs: https://learn.microsoft.com/en-us/azure/devops/organizations/security/security-best-practices?view=azure-devops